1. Field of the Invention
The invention relates to the field of circuit design and, more particularly, to a behavior manager for managing the behavior of algorithms when implementing a circuit design.
2. Description of the Related Art
Circuit designs, and particularly designs for Field Programmable Gate Arrays (FPGA's), have become increasingly complex and heterogeneous. The rapid increase of FPGA design complexity and size has driven several complex Xilinx FPGA devices to accommodate a few million gates. Modern circuit designs can include a variety of different components or resources including, but not limited to, registers, block Random Access Memory (RAM), multipliers, processors, and the like. This increasing complexity makes design tools, maintenance of design tools as well as placement and signal routing of circuit designs more cumbersome. Existing design tools can have multiple flows that fail to be uniform, further adding to the complexity in the tools and their maintenance. Furthermore, existing design tools do not provide an infrastructure that supports and facilitates rapid internal implementation changes whenever there is a corresponding external design flow change. External design flow changes are expected and initiated by new user and marketing requirements. In a competitive market place, the ability to facilitate and support product changes plays an important role in reducing the time to market.
Adding to the complexity and cumbersome management of FPGA software design code is the manner in which rules are currently managed and placed in the FPGA software design code. Rules are generally distributed throughout the design code and not centralized in a single area. Lack of centralization in this regard causes any rule-based infrastructure to suffer from increased complexity and maintenance.
Many of these shortcomings can be seen as it relates to user flows, although such shortcomings are not necessarily limited to such context. Xilinx software implementation tools currently support a number of user flows including a “conventional flow” and a set of “user interactive” flows. The conventional flow is characterized by a single design iteration while the user interactive flows require two (2) or more design iterations through the tools. These user interactive flows refer to a collection of 5 flows, namely Normal Guide Exact flow, Normal Guide Leverage flow, Incremental Design flow, Modular Design flow, and Partial Reconfiguration flow. Each flow addresses a specific set of customer needs.
Many of the tasks performed in these interactive flows relate to working with containers of grouped logic. Flows are determined in part by user specified command line parameters and user-specified constraints. Client software such as point tools read the parameters from the command line and the constraint files, and operate on the groups of logic with algorithms that are dependent on the particular flow that is being followed. The algorithms are fractured and branch into other algorithms depending on characteristics such as the flow information and the additional parameters that defines the grouped logic. As noted above, changes to the flow definition may require extensive modification to underlying algorithms.
In existing software systems, a specific implementation flow represents a high-level design implementation behavior that embodies a number of lower level algorithmic behaviors. Furthermore, each specific implementation flow influences one or more underlying individual point tools and the behaviors of its support algorithms. The distributed nature of flow information throughout various individual point tools and its algorithms has several major disadvantages. Since the flow information is interpreted in various tools and/or algorithms, the following shortcomings are encountered: (1) Each tool/algorithm can access and interpret the flow information in an inconsistent manner; (2) A change in a specific implementation flow may impact significant software changes to one or more point tools and/or algorithms; The engineering staff overhead to support such a change is non-trivial; (3) With a ripple affect of changes to one or more point tools, software robustness and testability become an issue; (4) Lastly, with the flow information dispersed into the point tools, no unified domain knowledge can be established. Consequently, it is difficult to support new flows or modify existing implementation flows under the current software paradigm. Note that the numerous user flows referenced above have created just one example where a lack of a centralized manager of algorithmic behavior has caused undue complications in design and support of software.